The popularity of the Internet and other private and public networks has resulted in increasing reliance on electronic transmission of data for both business and personal reasons. In many instances the data transmitted is of a personal or confidential nature. A user may provide credit card or other account information over the network to purchase goods or services. Sensitive and confidential business communications, emails, and documents are also transmitted over networks. It is necessary to provide security measures that protect such data as it is routed over the networks.
A popular protocol for electronically transmitting data is the Internet Protocol (IP). However, IP provides little security as the data within IP packets is not encrypted and may be accessed, viewed, and even altered by an eavesdropper. Thus, IP does not protect the confidentiality or authenticity of the data. These shortcomings have been addressed by the Internet Engineering Task Force (IETF), which developed a set of extensions to IP referred to as the Internet Protocol Security (IPSec) suite. The IPSec suite includes protocols such as encapsulating security protocol (ESP), and key management and exchange protocol (IKE).
The ESP protocol, documented mainly in IETF Request for Comments (RFC) 2406, is an authenticating and encrypting protocol that uses cryptographic mechanisms to provide integrity, source authentication, and confidentiality of data. A first network device, referred to as an initiator, and a second network device, referred to as a responder, transmit IP packets according to the ESP protocol to exchange data in a secure manner. According to the ESP protocol, some information in the ESP packet is encrypted, such as underlying payload data and a transport layer header, e.g. Transport Control Protocol (TCP) header or User Datagram Protocol (UDP) header.
The IKE protocol, documented mainly in IETF RFC 2409, provides a method for the initiator and responder to negotiate security settings used with the ESP IPSec format. The negotiated security settings form one or more data structures, called a security association (SA), which defines parameters such as the encryption algorithm, keys, and the lifetime of keys, used by ESP to protect the contents of the IP packet. Because ESP requires one or more established SAs, an IKE negotiation is executed before the ESP protocol is used. Once the IKE negotiation is complete, a secure session is formed between the initiator and responder.
Typically, the responder maintains a plurality of SAs per secure session. A first SA is for inbound traffic, i.e. packets sent from the initiator to the responder, and a second SA is for outbound traffic, i.e. packets sent from the responder to the initiator. The first and second SAs are referred to as IPSec SAs. The inbound traffic SA instructs the responder how to process incoming IPSec packets received from the initiator and the outbound traffic SA instructs the responder how to generate outbound IPSec packets destined for the initiator. Each IPSec SA has a corresponding selector used to define what type of packets should be encapsulated using the parameters of the IPSec SA. The initiator likewise maintains reciprocal inbound and outbound IPSec SAs for the secure connection. Other SAs may exist such as an IKE SA that is used as part of the IKE negotiation process.
The responder is capable of maintaining multiple secure sessions with one or more initiators in which case the responder maintains a set of inbound and outbound SAs for each session. The responder must have a mechanism to select the proper inbound and outbound SA when receiving and transmitting ESP packets. To that end, inbound packets include unique identification, including a security paramenter index (SPI), which in conjunction with other data allows the responder to identify and apply the proper inbound SA for received packets.
When the responder transmits an IP packet to a network device, it first determines, based on IPSec policy selectors, whether the packet is subject to IPSec processing. If the packet is subject to IPSec, the responder identifies the proper outbound SA based on packet parameters, including protocol type, source and destination IP address, and source and destination application ports. Because the responder maintains multiple secure connections, each of which may have its own associated outbound SA, it is important that the combination of these parameters be unique for each secure connection.
Recent proposals suggest methods for implementing the IPSec protocol suite in network environments using a network address translation device (NAT). An example of such a network includes a NAT connected to a plurality of network devices on an internal network as an interface between the internal network and an external network. Each network device has a private source IP address that is valid on the internal network but not valid on the external network. When a first network device sends an IP packet destined for the external network, the NAT intercepts the packet and replaces the private source IP address with an IP address valid on the external network, such as a public IP address assigned to the NAT. The NAT performs the same process for each network device, and in each case uses the same source public IP address. This process, known as address translation, allows multiple initiators behind the NAT to communicate over the external network with a single source IP address.
The NAT may also perform port translation (NAPT), i.e. changes an application source port in the transport layer header, when necessary, to ensure that each network device behind the NAT sends packets with a unique combination if IP addresses and ports over the external network. The unique combination provides the NAT with a mechanism to route response IP packets sent from devices on the external network to the proper network device on the internal network. NAPT allows multiple computers behind a NAT to use a single address to communicate with the same network device, i.e. same destination IP address, using typical well-known UDP and TCP ports.
As previously described, the transport layer header in ESP packets is encrypted. Thus, the application source port in the header is opaque to the NAT. The NAT cannot read and modify the source port preventing the port translation function of the NAT.
One known method that permits NATs to perform port translation on ESP packets is called UDP encapsulation. According to this method, the encrypted portion of the ESP packet is encapsulated into an unencrypted UDP packet. The unencrypted UDP packet includes a UDP header with unencrypted source and destination ports. For implementation reasons, such as taking advantage of mappings created during IKE negotiations, the source and destination port values in the unencrypted UDP header are typically selected as port 500 or 4500, the Internet assigned numbers authority (IANA) designated ports for IKE negotiations. The NAT can access and modify the source port in the added unencrypted UDP header, thereby permitting the NAT to perform both address and port translation on the ESP packets.
Although UDP encapsulation facilitates NAT traversal for ESP packets, it does not offer a complete solution for processing of the ESP packets at the responder. The unencrypted UDP ports do not correlate to the encrypted application ports. When two or more initiators behind a NAT maintain secure sessions with the same responder, the source and destination IP addresses will likely be the same because of the address translation provided by the NAT. Moreover, there is no guarantee that the source and destination application ports will be unique since the NAT uses the unencrypted UDP ports for the port translation and not the encrypted application ports. Thus, there is chance that two outbound SAs at the responder will be mapped to the same combination of protocol type, IP addresses and application ports. When this occurs, the responder cannot determine which of the two or more outbound SAs should be applied to a given outbound packet. Examples of scenarios that require a solution for this problem include configurations where several employees of the same company (behind NAT) use IPSec Virtual Private Network (VPN) clients to their VPN server and configurations where conference participants (behind the same NAT) use IPSec protected TCP or UDP based connections to the same Internet server.
One solution is for the responder to internally assign a unique source IP address to one of the initiators when a session conflict is detected. Although this solution may provide unique mappings for outbound SAs, there is danger that the assigned unique source IP address will conflict with the actual IP address of some other network device, or that the original source Internet address is meaningful to applications, functions in layers above IP, or other IPSec policy enforcement.
From the foregoing, it is evident that a solution is needed to allow a responding computer to maintain unique mappings for outbound security associations used in network environments that employ a NAT.